For now leave this aside, or bring it up-to-date with CBA.

Imo it should be up to the user to check whenever it's ready. This should only return false or an error code that it couldn't run. The removal of these waitUntilAndExecute would make the _onDisplay event redundant.

The display on which the QTE is drawn should be an argument, so that people can run it wherever they want to (e.g. Zeus interface). Because of comment below, this is no longer relevant.

I really dislike this strongly. It uses CBA settings for keybind sets, when we can use CBA keybinds instead.
This would allow for way more flexibility and customisability, as 3rd party mods or mod makers could add their own extra keybinds.

Register 4 keybinds. Here's an example (strings would need to be localised and improved):

["QTE Keybinds", QGVAR(keyUpQTE), ["QTE up key", "Up key used in QTE events."], {
    ["↑"] call FUNC(keyPressedQTE); // return
}, {}, [DIK_UP, [false, false, false]]] call CBA_fnc_addKeybind;

In fnc_keyPressedQTE, you'd check if the keypress is good or not:

params ["_eventQTE"];

// Check if the passed parameter is the next key in the QTE sequence
// If yes, continue
// If no, stop

Imo, we should make the QTE agonistic of the QTE chars themselves ("↑"). That should be configurable by the user. It will add an extra layer of complexity to the whole things, so we'll have to see if it's worth it.

Let's keep it simple and start with assigning keys to "↑" etc then we can look at expanding to other keys.

Personally have a problem with QTE events cuz it expands into Quick-Time Event events.

Making it Quick-Time Events ain't just 2 letters longer, I admit, but shouldn't matter:

Up key used in QTE events.
Up key used in Quick-Time Events.

The other headers are formatted different from this one.

A lot of tabs in this file at least.

Argument needs description.

It would be None, but the whole point of using a function over an event is so that you can return something.

We want to "override" input if it's a valid QTE keypress, meaning that e.g. if you have bound your arrow up key to move forwards, you wouldn't move forwards while you are doing a QTE.

Is this where we return true/false in terms of input override?

Yep

I'm still not a fan of this. Depending, we might have to wait indefinitely. It also means that multiple QTE can queue up, which could cause unforeseen headaches, albeit unlikely.

I think we'd be better off returning a boolean telling the caller if the QTE was successfully run or not.

As far as I can tell, there is no reason to use a hashmap object.

You can't pass _this when using default arguments. The default arguments are not inserted into _this, you'll have to pass each argument individually in an array.

Regardless, _this here does not make sense. Pass [_object, _start_time, _timeout, _max_distance] and read those in the loop instead - unless reading from GVAR(QTEArgs) is faster?

All the code should be added before this line.

However, more importantly adding keybinds in common doesn't work. keybinding depends on common, meaning the code below is called when CBA_fnc_addKeybind is not defined.

This means that this code needs to be moved to another component. I'm not sure if events is the right place or if we should add another component, just for this.

Don't need this file, remove it.

Remove along with the file.

Order them alphabetically.

GVAR(QTERunning) is undefined on the first time it's run.

You could move this line above the params line, as this doesn't require any arguments.

Minor typo has slipped in (change where necessary).

Unnecessary parenthesis:

I think having player distance _object > _maxDistance as a condition is a very limiting factor. In some cases one might not want or need to have such a condition, but would rather use others.
The condition code should be passed by the user, it would be {false} by default (meaning the timeout would be the default method of ending the QTE if it isn't solved in time). object and maxDistance would no longer be needed.

You'd evaluate it by calling _args call _condition, with _args being the same args as the event/function one.
The function header would need to be adjusted accordingly.

Why not go a step further and remove the timeout and just pass [_args, _elapsedTime]. This would allow for unlimited time variants too. Its also standard for all functions then.

Since this is a public function, we need to sanitise the input:

You need to check if the input are valid (e.g. an empty QTE sequence should not be allowed).

I haven't taken into account the other proposals I've made, so you'll need to adapt accordingly.